IEEE 829
La documentación de la prueba de software es el elemento vital que eleva las actividades experimentales al nivel de una prueba de software.[1] Organizaciones internacionales como IEEE e ISO han publicado estándares para la documentación de pruebas de software.
Estado de IEEE 829
[editar]IEEE 829-2008 ha sido reemplazado por ISO / IEC / IEEE 29119-3: 2013.[2]
Antecedentes de IEEE 829
[editar]IEEE 829-2008, también conocido como el Estándar 829 para la documentación de prueba de software y sistema, era un estándar IEEE que especificaba la forma de un conjunto de documentos para su uso en ocho etapas definidas de prueba de software y prueba de sistema, cada etapa potencialmente produciendo su propia tipo de documento separado. La norma especificaba el formato de estos documentos, pero no estipulaba si debían producirse todos, ni incluía ningún criterio con respecto al contenido adecuado para estos documentos. Estos fueron un asunto de juicio fuera del alcance de la norma.
Documentos requeridos por IEEE 829
[editar]Los documentos son:
- Plan de prueba maestro (MTP): el propósito del Plan de prueba maestro (MTP) es proporcionar un documento general de planificación de prueba y gestión de prueba para múltiples niveles de prueba (ya sea dentro de un proyecto o en varios proyectos).
- Plan de prueba de nivel (LTP): para cada LTP se debe describir el alcance, el enfoque, los recursos y el cronograma de las actividades de prueba para su nivel de prueba específico. Es necesario identificar los elementos que se prueban, las características que se probarán, las tareas de prueba que se realizarán, el personal responsable de cada tarea y los riesgos asociados.
- Diseño de prueba de nivel (LTD): detalla los casos de prueba y los resultados esperados, así como los criterios de aprobación de la prueba.
- Caso de prueba de nivel (LTC): especifica los datos de prueba para usar en la ejecución de los casos de prueba identificados en el Diseño de prueba de nivel.
- Procedimiento de prueba de nivel (LTPr): detalla cómo ejecutar cada prueba, incluidas las condiciones previas de configuración y los pasos que deben seguirse.
- Registro de prueba de nivel (LTL): para proporcionar un registro cronológico de detalles relevantes sobre la ejecución de las pruebas, por ejemplo, registrar qué casos de prueba se ejecutaron, quién los ejecutó, en qué orden y si cada prueba pasó o no.
- Informe de anomalías (AR): para documentar cualquier evento que ocurra durante el proceso de prueba que requiera investigación. Esto puede denominarse un problema, incidente de prueba, defecto, problema, problema, anomalía o informe de error. Este documento se nombra deliberadamente como un informe de anomalía y no como un informe de falla. La razón es que puede producirse una discrepancia entre los resultados esperados y los reales por una serie de razones distintas de una falla en el sistema. Estos incluyen los resultados esperados incorrectos, la prueba se ejecutó incorrectamente o la inconsistencia en los requisitos, lo que significa que se podría hacer más de una interpretación. El informe consta de todos los detalles del incidente, como los resultados reales y esperados, cuándo falló, y cualquier evidencia de apoyo que ayudará en su resolución. El informe también incluirá, si es posible, una evaluación del impacto de un incidente después de la prueba.
- Informe de estado de prueba intermedia de nivel (LITSR): para resumir los resultados provisionales de las actividades de prueba designadas y opcionalmente para proporcionar evaluaciones y recomendaciones basadas en los resultados para el nivel de prueba específico.
- Informe de prueba de nivel (LTR): para resumir los resultados de las actividades de prueba designadas y proporcionar evaluaciones y recomendaciones basadas en los resultados después de que la ejecución de la prueba haya finalizado para el nivel de prueba específico.
- Informe de prueba maestro (MTR): para resumir los resultados de los niveles de las actividades de prueba designadas y proporcionar evaluaciones basadas en estos resultados. Este informe puede ser utilizado por cualquier organización que use el MTP. Un informe de gestión que proporciona cualquier información importante descubierta por las pruebas realizadas, e incluye evaluaciones de la calidad del esfuerzo de prueba, la calidad del sistema de software bajo prueba y las estadísticas derivadas de los informes de anomalías. El informe también registra qué pruebas se realizaron y cuánto tiempo tomó, para mejorar cualquier planificación de pruebas futuras. Este documento final se utiliza para indicar si el sistema de software bajo prueba es apto para el propósito de acuerdo con si cumple con los criterios de aceptación definidos por las partes interesadas del proyecto.
Uso de IEEE 829
[editar]El estándar formó parte del programa de capacitación de la Fundación ISEB y los Certificados de Practicante en Pruebas de Software promovidos por la British Computer Society. ISTQB, luego de la formación de su propio plan de estudios basado en el plan de estudios de ISEB y ASQF de Alemania, también adoptó IEEE 829 como el estándar de referencia para la documentación de pruebas de software y sistemas.
El Dr. David Gelperin y el Dr. William C. Hetzel desarrollaron la metodología del Proceso Sistemático de Prueba y Evaluación (STEP) para implementar el Estándar IEEE-829 original para la Documentación de Prueba de Software.[3]
Enlaces externos
[editar]- IEEE Std 829-2008, estándar IEEE para software y documentación de prueba del sistema
- BS7925-2, estándar para pruebas de componentes de software
Referencias
[editar]- ↑ «Software Test Documentation – How should Test Documentation look like?». THE-SOFTWARE-EXPERTS. Consultado el 18 de enero de 2017.
- ↑ «IEEE Products and Projects Status Report». standards.ieee.org. Archivado desde el original el 13 de octubre de 2017. Consultado el 13 de octubre de 2017.
- ↑ Rick D. Craig; Stefan P. Jaskiel (2002). Systematic Software Testing. Artech House. p. 4. ISBN 978-1-58053-792-6.
| Control de autoridades |
|
|---|
Datos: Q1431617